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REMARKS 

Claims 1-8, 10-23, 25-38, and 41-45 are pending. 

Applicant notes and appreciates withdrawal of the finality of the prior office 

action. 

In the present Office Action, claims 1-8, 10-23, 25-38, and 41-45 stand rejected 
under 35 U.S.C. §103(a) as being unpatentable over U.S. Patent No. 6,822,957 

t 

(hereinafter "Schuster"), in view of U.S. Patent No. 6,577,642 (hereinafter "Fijolek"), 
and in further view of newly cited U.S. Patent No. 6,958,992 (hereinafter "Lee"). 
Applicant has reviewed the references, including the newly cited art, and believes each of 
the pending claims are patentably distinguishable from the cited art. Accordingly, 
Applicant respectfully traverses the rejections and requests reconsideration in view of the 
following comments. 

A prima facie case of obviousness of a claimed invention is not established unless 
all the claim limitations are taught or suggested by the cited prior art. Applicant 
respectfully submits that each of the independent claims 1, 16, and 31 recite a 
combination of features not taught or suggested by the cited art. For example, in the 
present Office Action, the Examiner states: 

"Schuster et al. do not disclose explicitly receiving an identifier from 
the IP telephone; determining if a MAC ID for the IP telephone is 
valid; if the MAC ID is determined to be valid, determining if the 
identifier is valid. Fijolek et al. disclose the limitation of determining if 
a MAC ID for the CM is valid; if the MAC ID is determined to be 
valid (column 2L lines 12 - 30) ." (emphasis added). 

The cited portion of Fijolek is reproduced below: 

"CMTS 12 stores a pair of network address values in the ARP table, 
the IP 54 address of the selected network host interface from the 
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DHCP 66 yiaddr- field 126 and a Network Point of Attachment 
("NPA") address. In one preferred embodiment of the present 
invention, The NPA address is a MAC 44 layer address for the CM 16 
via a downstream cable channel. The IP/NPA address pair are stored in 
local routing tables with the IP/NPA addresses of hosts (e.g., the CMs 
16) that are attached to cable network 14. 

At Step 210, the CMTS 12 sends the DHCPACK message to the CM 
16 via the cable network 14. At Step 212, the CM 16 receives the 
DHCPACK message, and along with the CMTS 12 has addresses for a 
"virtual connection 1 ' between the data network 28 and the CM 16. 
When data packets arrive on the IP 54 address for the selected CM 16 
they are sent to the CMTS 12 and the CMTS 12 forwards them using a 
NPA (i.e., a MAC 44 address) from the routing tables on a 
downstream channel via the cable network 14 to the CM 16." 

However, this disclosure of Fijolek merely describes the CMTS may store 
EP/NPA address pairs in an ARP table. This disclosure additional describes the CMTS 
may forward messages using the NPA (e.g., a MAC address). However, nothing in this 
disclosure teaches or suggests "determining if a MAC ID for the CM is valid; if the MAC 
ID, is determined to be valid" as suggested by the examiner. In addition, the Applicant has 
reviewed the entire Fijolek reference and finds no disclosure or suggestion concerning 
determining if a MAC ID is valid. For at least these reasons, the claims are patentably 
distinguishable from the combination of cited art. 

In addition to the above, the examiner further states on page 3 of the present 
Office Action: 



"However, Fijolek et al. also do not disclose explicitly receiving an 
identifier from the IP telephone; determining if a MAC ID for the IP 
telephone is valid; if the MAC ID is determined to be valid, 
determining if the identifier is valid. Lee et al. disclose the limitation 
of receiving an identifier from the DP telephone (recited "IP phone then 
sends a request for registration to the IP phone service provider, which 
includes its MAC address and set type" as an identifier from the IP 
telephone; column 3, lines 16-32, Fig. 3, element 318, Reg Device 
(MAC, IP address, Set Type); determining if a MAC ID for the IP 
telephone is valid (recited "upon receipt of the validation request" as 
determining if a MAC ID for the EP telephone is valid; column 3, lines 
44 - 45, Fig. 3, elements 334 Validate PIN(MAC,PIN)); if the MAC 
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ID is determined to be valid, determining if the identifier is valid 
(recited "the access code is then validated" as the MAC ID is 
determined to be valid, and" Valid PIN" as determining if the identifier 
is valid; column 3, lines 49 - 55, FIG. 3, element 336 Valid 
PIN(MAC))." 



However, Applicant disagrees with the examiner's characterization as to what 
disclosed by Lee. Lee discloses the following: 



"FIG. 3 shows a data flow for registration of an unregistered IP phone 
102 on the IP phone switch 100 where a PIN has been assigned to a 
user, but a MAC address has not been associated with the PIN. The 
composition of the PIN includes an access code and a DN . 

To initialize the IP phone switch 100, the set registration process 204 
requests 310 and receives 312 the information from the OAM 206 
database for the lookup table. In order to boot-up the IP phone 102 for 
the IP phone switch 100, the EP phone 102 has to establish an IP socket 
with the IP phone switch 100, and send a request 320 for registration 
to the IP phone switch 100. Specifically, the IP phone 102 
communicates with the DHCP server 302 to obtain an IP address for 
itself as shown at 314. The DHCP server 302 further directs the IP 
phone 102 to get the necessary socket software from a Trivial File 
Transfer Protocol (TFTP) server 304. The IP phone 102 downloads 
316 and executes the software to establish the IP socket to the IP 
phone service provider 202. The IP phone 102 then sends a request 
318 for registration to the IP phone service provider 202, which 
includes its MAC address and set type. The IP phone service provider 
202 then sends an Open Port request 320 with the MAC address, the 
set type, and the IP address (associated information) to the set 
registration process 204 for registration of the IP phone 102. 

The set registration process 204 upon receiving the Open Port request 
320 checks the information against its lookup table of data shared with 
OAM 206 as shown at 322. In the present example of an unregistered 
IP phone 102, as there is no match 324 for the MAC address, the set 
registration process 204 sends a message to request a PIN 326, 328 
from the user of the IP phone 102. The IP phone 1 02 in turn displays a 
message requesting the user to enter a PIN. Upon receipt of the PIN 
from the user, the IP phone sends the PIN 330 to the IP phone service 
provider 204, which then sends an Open Port PIN request 332 with the 
PIN and associated information to the set registration process 204. The 
set registration process 204 in turn sends a validation request 334 with 
the PIN and the MAC address to the OAM 206. 
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The QAM 206, upon receipt of the validation request 334, strips the 
access code and DN from the PIN. The access code is then validated . 
The association of the DN with the MAC address is set up in the OAM 
206 for directing calls accordingly. Upon completion of the set up, the 
OAM 206 sends a message, Valid PEN 336, to the set registration 
process 204 indicating that the set is registered. The lookup table is 
then updated in both the OAM 206 and the set registration process 
204.." 

As seen from the above, a user PIN includes an access code and a DN (directory 
number). The registration process 204 receives an Open Port request with MAC address, 
set type, and IP address from the IP phone service provider. If the IP phone is 
unregistered, there is currently no associated MAC address in the database. Therefore, the 
registration process sends a request for a PIN to the IP phone. The IP phone returns the 
PIN (the user PIN includes an access code and a DN (directory number)). The 
registration process then sends a validation request with the PIN and MAC address to the 
OAM (database). The OAM then strips the access code and DN from the PIN and 
validates the access code. The association between the DN and the MAC address is then 
set up in the OAM database. Note that there is no validation of the MAC address in Lee. 
In contrast, Lee teaches validating the access code. Should the access code be validated, 
the received MAC address is associated with the DN. Therefore, Lee does not disclose 
"determining if a MAC ID for the IP telephone is valid (recited "upon receipt of the 
validation request" as determining if a MAC ID for the DP telephone is valid" as 
suggested. Rather, upon receipt of the validation request, the access code is validated - 
not the MAC address. 

Further, Lee does not disclose "if the MAC ID is determined to be valid, 
determining if the identifier is valid (recited "the access code is then validated" as the 
MAC ID is determined to be valid, and "Valid PIN" as determining if the identifier is 
valid". Rather, Lee discloses validating the access code and sending a Valid PIN 
message. Sending the valid PIN message is not a separate validation process. Rather, the 
valid PIN message is in response to validating the access code and completion of the set 
up. Accordingly, for at least these additional reasons concerning Lee, the claims are 
patentably distinguished from the cited art. As not all of the features of the claims are 
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disclosed by the combination of cited art, a prima facie case of obviousness is not 
established. Further, were one motivated to make such a combination, the combination of 
cited art would not produce the presently claimed invention. 

In view of the above, Applicant submits that all claims are patentably 
distinguishable from the cited art. However, should the examiner believe otherwise, the 
below signed representative would appreciate and requests a telephone interview (512) 
853-8866 in order to facilitate a resolution. 
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CONCLUSION 



Applicant submits the application is in condition for allowance, and an early 
notice to that effect is requested. 



If any extensions of time (under 37 C.F.R. § 1.136) are necessary to prevent the 
above referenced application(s) from becoming abandoned, Applicant(s) hereby petition 
for such extensions. If any fees are due, the Commissioner is authorized to charge said 
fees to Meyertons, Hood, Kivlin, Kowert & Goetzel PC Deposit Account No. 50- 
1505/5686-00300/RDR. 



Also enclosed herewith are the following items: 
3 Return Receipt Postcard 



Respectfully submitted, 




Rory E>. Rankin 
Reg. §io. 47,884 

ATTORNEY FOR APPLICANT(S) 



Meyertons, Hood, Kivlin, 
Kowert & Goetzel PC 
P.O. Box 398 
Austin, TX 78767-0398 
Phone: (512) 853-8800 
Date: September 13. 2006 
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